Greptile Summary

This PR wires the Lean Hive simulator suites into GitHub Actions by adding a docker_build job that exports the ethlambda image as an artifact and a run-hive matrix job covering nine simulator categories. A results-checker script parses Hive JSON output and surfaces failures in the step summary.

• docker_build is never triggered: its if guard references needs.detect-changes.outputs.run_tests, but no detect-changes job exists in the workflow and needs: detect-changes is not declared — the condition is permanently false, skipping docker_build and every dependent run-hive job on every run.
• Failure artifact upload has a logic gap: the upload step only fires when the results-checker script fails, not when the Hive simulation step itself crashes; the verify-hive-results step is skipped on simulation failure, so its conclusion is never 'failure' and no artifacts are uploaded.
• Dead devnet3 config: clients.yaml registers both devnet3 and devnet4, but the workflow only uses ethlambda_devnet4.

Confidence Score: 3/5

Safe to merge from a runtime-behavior standpoint — no client code is changed — but the new CI jobs will never execute as written.

The docker_build job references a detect-changes job that does not exist anywhere in the workflow, making its if condition always false. All nine Hive matrix jobs depend on docker_build, so they are also permanently skipped. The PR's stated goal of running Lean Hive simulators in CI is entirely unmet until this is fixed. There is also a secondary gap where simulation-level crashes produce no uploaded artifacts.

ci.yml needs the if condition on docker_build either removed or replaced with a valid guard; the failure-artifact upload condition also needs revision.

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
.github/workflows/ci.yml:150-153
**`docker_build` always skipped — `detect-changes` job does not exist**

The `if` condition references `needs.detect-changes.outputs.run_tests`, but `docker_build` has no `needs: detect-changes` declaration and the workflow defines no `detect-changes` job at all. GitHub Actions evaluates `needs.detect-changes` as an empty context, so the expression `needs.detect-changes.outputs.run_tests == 'true'` is permanently `false`. Every run of this workflow will skip `docker_build`, and because `run-hive` declares `needs: docker_build`, every Hive matrix job is skipped as well — making the entire new CI path a no-op.

### Issue 2 of 3
.github/workflows/ci.yml:268-274
**Failure artifacts not uploaded when the Hive simulation itself crashes**

The upload condition `failure() && steps.verify-hive-results.conclusion == 'failure'` only fires when the explicit results-checker script exits non-zero. If the `Run Hive Simulation` step itself fails (e.g., Hive crashes, network timeout, bad Docker image), the `Check Hive Results For Failures` step is skipped (its guard is `if: success()`), leaving `steps.verify-hive-results.conclusion == 'skipped'`. The compound condition is never satisfied, so no artifacts are uploaded on simulation-level failures — exactly the case where diagnostic logs would be most useful.

### Issue 3 of 3
.github/workflows/ci.yml:252-260
**`client` field hard-codes `devnet4` and ignores the `devnet3` nametag**

`clients.yaml` registers both `ethlambda` with `devnet3` and `ethlambda` with `devnet4`, but `client: ethlambda_devnet4` is used unconditionally in the simulation step. The `devnet3` entry appears to be dead config — if it is truly needed for some simulators, it should be referenced in the matrix; if not, it should be removed from `clients.yaml` to avoid confusion.

_{Reviews (1): Last reviewed commit: "ci: add Hive config for both ethlambda d..." | Re-trigger Greptile}

Reviewed this from a security angle since it touches CI and comes from outside the org. Overall it's in good shape — workflow correctly uses pull_request (not pull_request_target), no new secrets are introduced, push: false on the docker build, and check-hive-results.sh is properly quoted. Two hardening suggestions:

1. Add an explicit permissions: block.
The new jobs inherit the workflow defaults. For fork PRs the token is read-only anyway, but pinning permissions explicitly makes the intent obvious and protects against future workflow changes silently widening scope. Suggestion:

docker_build:
  permissions:
    contents: read
  ...
run-hive:
  permissions:
    contents: read
  ...

2. Pin ethpandaops/hive-github-action by commit SHA, not by tag.
Tag pins (@v0.5.0) can be moved if the upstream tag is force-pushed or compromised. Replacing with the commit SHA + a comment with the version is the standard hardening:

uses: ethpandaops/hive-github-action@1aa8d73dad34de13afbb3113ab16c1a462d2fbc3  # v0.5.0

Optional: while you're there, v0.5.0 is a few releases behind latest (v0.6.3) — happy to keep v0.5.0 for parity with ethrex's workflow, or bump if you'd prefer to be on the current release.

Neither is blocking — the PR is safe to run as-is from a fork — but these would harden it. Functional/cosmetic feedback to follow in a separate comment.

Reviewed this from a security angle since it touches CI and comes from outside the org. Overall it's in good shape — workflow correctly uses pull_request (not pull_request_target), no new secrets are introduced, push: false on the docker build, and check-hive-results.sh is properly quoted. Two hardening suggestions:

1. Add an explicit permissions: block. The new jobs inherit the workflow defaults. For fork PRs the token is read-only anyway, but pinning permissions explicitly makes the intent obvious and protects against future workflow changes silently widening scope. Suggestion:

docker_build:
  permissions:
    contents: read
  ...
run-hive:
  permissions:
    contents: read
  ...

2. Pin ethpandaops/hive-github-action by commit SHA, not by tag. Tag pins (@v0.5.0) can be moved if the upstream tag is force-pushed or compromised. Replacing with the commit SHA + a comment with the version is the standard hardening:

uses: ethpandaops/hive-github-action@1aa8d73dad34de13afbb3113ab16c1a462d2fbc3  # v0.5.0

Optional: while you're there, v0.5.0 is a few releases behind latest (v0.6.3) — happy to keep v0.5.0 for parity with ethrex's workflow, or bump if you'd prefer to be on the current release.

Neither is blocking — the PR is safe to run as-is from a fork — but these would harden it. Functional/cosmetic feedback to follow in a separate comment.

I will work on the reviews. Thanks!